System and method for navigating and deleting descriptors

ABSTRACT

A system comprising at least two devices coupled to a bus wherein at least one device contains a descriptor hierarchy. A data structure has a descriptor specifier which specifies an entry by a list identifier and an object identifier.

This application claims the benefit of the earlier filing date ofco-pending provisional application of Jon Ebbe Brelin and Hisato Shimaentitled, “System and Methodfor Accessing Navigating Descriptors,” Ser.No. 09/541,145, filed Mar. 31, 2000 and incorporated herein byreference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to data retrieval in audio, video oraudio/video interconnected systems for home or office use and, moreparticularly, to a system and method for navigating a descriptorhierarchy within such systems.

2. Background

Data retrieval from a high speed serial bus such as an Institute ofElectrical and Electronics Engineers (IEEE) 1394 standard serial bus,std 1394-1995, Standard For A High Performance Serial Bus, (Aug. 30,1996) (hereinafter referred to as the “IEEE 1394 standard serial bus”)incorporates unnecessary operations and burdens an audio video/control(“AV/C”) protocol that uses the IEEE 1394 standard serial bus. Oneillustration of this problem relates to the IEEE 1394 standard serialbus that uses a controller device to navigate a descriptor hierarchy ina target device (also referred to herein as a data structure hierarchy)and the controller sends a command to, for example, a descriptor toopen. An AV/C controller (“controller”) is a device at a serial bus nodethat sends AV/C commands to control a remote AV/C device. A target'sdescriptor (“target”) has defined fields used for sharing deviceinformation and which may be modified by any device. When navigating adescriptor hierarchy, a controller, using conventional AV/C commands,opens and reads a descriptor on a target device containing information.This information may pertain, for example, to a destination file.

Navigating a descriptor hierarchy involves a controller opening andreading descriptors that are arranged in a hierarchical format.Descriptors in a descriptor hierarchy may be read in a forward or in abackward approach. A forward approach involves opening and reading adescriptor to determine the next descriptor to open. A conventionalbackward approach generally involves the controller memorizing thedescriptors it has opened, and reversing the forward navigation path.

To navigate descriptors, the controller sends an OPEN DESCRIPTOR commandwith a descriptor_specifier data structure specifying a list. Entrydescriptors within the list may contain information about the nexthierarchical list such as its child list. Using the READ DESCRIPTORcommand, an entry's child list identifier (i.e. child_list_ID) is thenreturned to the controller and the next list which is a level below maybe opened. Generally, there are two conventional approaches to refer toan entry descriptor in a list when issuing commands. First,descriptor_specifier 2016 may be used to specify an entry descriptor bythe identifier of its list (i.e. list_ID) and then by its entryposition. Second, another descriptor specifier such asdescriptor_specifier 21 ₁₆ may be used to specify an entry descriptor byits root list identifier (i.e. root_list_ID), its list type (i.e.list-type), and then by its object identifier (i.e. object_ID).

There are numerous disadvantages to these conventional approaches. Forexample, some AV/C subunits on the IEEE 1394 standard serial bus arerequired to support specific entry descriptors by entry position. OtherAV/C subunits are required to support descriptors by an objectidentifier. Consequently, controllers bear the burden of supporting bothtypes of access methods depending upon the target that it iscontrolling.

Another disadvantage is that if a controller has access to the listidentifier in which the entry exists, the controller is generallyrequired to support specifying that entry by an entry position.Specifying the entry by an entry position can be problematic. Forinstance, a list generally contains a plurality of entries and if one ofthe middle entries is deleted, their positions shift. For the purpose ofillustration, assume that a list contains five entries. If the thirdentry position, for example, is deleted, the fourth entry position andthe fifth entry position move and become the new third and fourth entrypositions. This causes a problem because invalid information may besupplied to a target by a controller that contains the old entryposition.

Yet another disadvantage is that if an AV/C target uses the objectidentifier reference (i.e. a field in the entry that identifies theobject for which the entry represents), the AV/C target may also specifyan ambiguous entry since object identifiers are unique only within aparticular list_type and there may be many lists in the target of thesame list_type. This is also problematic since the list is alreadyopened by a list identifier and the AV/C subunit then must support thatsame list with a redundant specification such as the list_typespecification when using object_ID specification.

Another conventional approach for specifying descriptors in a descriptorhierarchy relates to the data that identifies the lists and entries inthe descriptor hierarchy for navigation purposes. Presently, if acontroller navigates a descriptor hierarchy in order to viewhierarchical data, the controller navigates in a forward direction. Thecontroller reads a descriptor and determines if any root lists or childlists exist. The controller may then open those lists. However, theselists typically lack information about their parent descriptor. In orderto recall the parent descriptor identifier, the controller must trackthe descriptors that it has navigated by storing the identifications(“IDs”) of the parent entry and child list descriptors within thestorage device of the controller. However, other controllers may modifythe descriptor hierarchy in a target device at any time causing thefirst controller to have erroneous data. It is therefore desirable tohave a system of navigating a descriptor hierarchy that eliminates theredundancies, ambiguities, complexities and other disadvantagesassociated with the conventional approaches.

In addition to navigating descriptor hierarchies, conventional systemslack a straightforward way of deleting descriptors in a hierarchy. Forexample, generally two subfunctions in the WRITE DESCRIPTOR commanddefined in the AV/C documentation may be used to delete descriptor data.However, these two subfunctions do not account for the hierarchicalnature of the descriptor structure. For instance, if the child_list_IDfield in an entry is deleted using the WRITE DESCRIPTOR command, thereis no indication in the command how the entry's child_list should bedeleted. It is therefore also desirable to have a system and method in adescriptor hierarchy that defines how to delete descriptors undervarious conditions.

SUMMARY OF THE INVENTION

A method is disclosed for coupling a first device and a second device toa bus. Parent descriptor information blocks are placed into a descriptorhierarchy data structure for AV/C devices. The descriptor specifierspecifies an entry by a list identifier and an object identifier.Additional features, embodiments, and benefits will be evident in viewof the figures and detailed description presented herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitedin the figures of the accompanying drawings, in which like referencesindicate similar elements and in which:

FIG. 1 is a block diagram of one embodiment for multimedia networkincluding various consumer electronic devices coupled through a highspeed serial bus;

FIG. 2 is a block diagram of one embodiment of a controller AV/C deviceand a target AV/C device with a descriptor hierarchy residing in thetarget node of the IEEE 1394 standard serial high speed serial bus;

FIG. 3 illustrates descriptor_specifier data structure used bycontrollers in AV/C descriptor commands and by targets in itsdescriptors;

FIG. 4 illustrates in one embodiment a descriptor hierarchy conceptualdiagram;

FIG. 5 illustrates in one embodiment a parent descriptor info block fora child list that is to be placed in the list descriptor's extendedinformation area;

FIG. 6 illustrates in one embodiment, a parent descriptor info block fora root list that would be placed in the root list descriptor's extendedinformation area;

FIG. 7 illustrates in one embodiment the list descriptor that mayinclude parent entry descriptors;

FIG. 8 is a flow diagram of one embodiment related to using the newdescriptor specifier in a command to access a descriptor;

FIG. 9 is a flow diagram of one embodiment for embedding informationabout the parent entry or SID within the list descriptor for backwardsnavigability.

FIG. 10 illustrates in one embodiment of deleting a child list bydeleting the child list in the descriptor specifier;

FIG. 11 illustrates a child list being deleted by deleting the parententry descriptor in the descriptor_specifier;

FIG. 12 illustrates deleting a list and its child lists by deleting thelist descriptor specified in the descriptor specifier;

FIG. 13 illustrates a root list being deleted;

FIG. 14 illustrates a new DELETE DESCRIPTOR command that may be used todelete various descriptors;

FIG. 15 illustrates a response frame of the DELETE DESCRIPTOR command;

FIG. 16 illustrates a descriptor being deleted when another descriptorin the descriptor hierarchy is open for a write operation and anotherdescriptor is open for a read operation; and

FIG. 17 illustrates the descriptor hierarchy after descriptors in thedescriptor hierarchy of FIG. 16 have been deleted.

DETAILED DESCRIPTION

In one embodiment, a system is disclosed in which a device is coupled toanother device that contains shared navigable information by a bus, suchas a IEEE 1394 standard serial bus. A type of descriptor specifier isintroduced which specifies an entry by its list_ID and then itsobject_ID. In this system, descriptor navigation information is entirelycontained within the descriptor hierarchy allowing for a direct route ina backward direction when navigating the data within the descriptorhierarchy. This reduces the burden caused by multiple controller storageof navigation data.

In another embodiment, a parent descriptor information block is placedin both types of list descriptors. This allows a controller to navigatedescriptors in a backward direction without having to store the listidentifier of the list descriptors within the storage device of one ormore controllers.

In yet another embodiment, a DELETE DESCRIPTOR is used for cascadedeleting descriptors in a descriptor hierarchy.

In the following description, numerous specific details are set forth toprovide a thorough understanding of the invention. However, it will beunderstood by one of ordinary skill in the art that the invention may bepracticed without these specific details. In other instances, well knownstructures and techniques have not been shown in detail to avoidobscuring the invention.

FIG. 1 is a block diagram of one embodiment for multimedia network 100,including various consumer electronic devices coupled through a highspeed serial bus 160. The high speed serial bus 160 may be, for example,an IEEE 1394 standard serial bus. In one embodiment, the multimedianetwork 100 may be located in one physical building, such as a home oran office. Multimedia network 100 may include digital video camera 110,digital video monitor 120, personal computer 130, palm pilot 135,digital video cassette recorder (“VCR”) 140, and printer 145. High speedserial bus 160 supports communication of digital audio/video data andcomputer transmission data between the network devices. Digital videocamera 110, digital VCR 140, printer 145, or any other consumerelectronic device typically do not have direct Internet access whereascomputer 130 and palm pilot 135 may be configured to have Internetaccess. Network 210 that includes networks such as an intranet or aglobal network such as the Internet, interfaces with computer 130 andpalm pilot 135 through, for example, a telephone line (not shown) orwireless communication.

FIG. 2 is a block diagram of one embodiment of two AV/C devices such ascomputer 130 and camera 100 shown in FIG. 1 residing in two nodes of theIEEE 1394 standard serial bus. System 400 includes controller device(also referred to herein as a second device) 410 connected to a targetdevice (also referred to herein as a first device) 420. Target device420 may be digital video camera (“DVC”). Target device 420 includesstorage 430 such as memory for storing data and several descriptors(data structures) 405, 450, 460, and 470. Data may be transferred to andfrom descriptors 405, 450, 460, and 470.

Each descriptor 405, 450, 460, and 470 has a structured data interfacecontaining information pertaining to features of device 420. A childdescriptor is to the right of its parent descriptor, and a parentdescriptor is to the left of its child descriptor. The identification ofa child descriptor is maintained within the parent descriptor. Forforward navigation, controller 410 accesses subunit identifierdescriptor (“SID”) 405. Controller 410 uses the knowndescriptor_specifier type “0” representing the SID 405. Using SID 405,controller 410 can open a root list descriptor 450. Thereafter, childlists 460 and 470 (the child list is also referred to herein as thesecond list) can be opened by reading child_list_IDs in the parententries in the root list 450.

In one embodiment, list descriptors 450, 460, and 470 each include entrydescriptors with object_IDs. This allows controller 410 to access avariety of information from a target device 420 by using a singledescriptor specifier type, as shown in FIG. 3, in a descriptor commandsuch as a READ DESCRIPTOR. This descriptor specifier in a descriptorcommand specifies the list identifier and the object identifier for aunique entry descriptor. By including the list identifier and the objectidentifier, the descriptor command is used by controller 410 to accessan entry. More specifically, controller 410 is able to open, read, orwrite the entry by specifying both the list identifier and the objectidentifer for that entry.

The result of using a descriptor specifier with a list identifier and anobject identifier (i.e. list_ID, object_ID) for an entry descriptor isthat the descriptor specification is more precise which allows highspeed serial bus 160 to be more efficient than typical high speed serialbuses. For example, AV/C subunits will no longer be required to supportspecifying descriptors by list_ID, entry_position and/or supportspecifying descriptors by root_list_ID, list_type, or object_ID whichcan result in an unreliable or an ambiguous specification. Additionally,contrary to typical techniques, by using an entry descriptor thatincludes both a list identifier and an object identifier, if an entryposition is dynamically changed, the entry position still maintains itsuniqueness. The techniques of the invention eliminate the need ofdesignating and supporting the ambiguous identifier “list_type” bymaintaining both an object identifier and a list identifier in the samedescriptor specifier. Furthermore, a descriptor specifier having a listidentifier and an object identifier is not ambiguous. Accordingly, lessburden is placed on controller 410 such as computer 130 compared toconventional techniques when the descriptor specifier having a listidentifier and an object identifier is used as a return path fornavigating descriptor hierarchies.

FIG. 4 illustrates one embodiment of navigating a descriptor hierarchyin a forward direction and a backward direction. Controller 410 isconnected to target device 515 having a plurality of descriptors (405,520, 540, 550, and 560). In this embodiment, a descriptor specifierhaving a list identifier and an object identifier is required.

To navigate a descriptor hierarchy, backwards from, for example, a rootlist, refer to position 522. At position 522 of descriptor 520, theparent descriptor information block refers to SID 405 as its parent.While the root list is open, controller 410 reads parent descriptorinformation block 522 to determine that SID 405 is the parent androot_list_ID is its list_ID. Additionally, child lists for descriptors540, 550, and 560 may be opened by reading entries in the root list.

There is a parent descriptor information block within descriptors 540,550, and 560 that refer to the root list. For instance, parentdescriptor information block 542 for a child list of descriptor 540refers to parent entry 1 528 of descriptor 520, parent descriptorinformation block 552 for a child list of descriptor 550 refers toparent entry 2 526 of descriptor 520, parent descriptor informationblock 562 for a child list of descriptor 560 refers to parent entry 3524 of descriptor 520. While a child list is open, controller 410 readsa parent descriptor information block for the particular child list todetermine which specific list and entry in the descriptor hierarchy isits parent.

While navigating descriptors, controller 410 may use descriptors such asdescriptors 520 and 540 and move in a backward direction following, forexample, its original path of descriptors 540 to 520. Typical techniquesallow controller 410 to move in a backward direction provided thatcontroller 410 keeps track of the descriptor that controller 420previously navigated. A controller tracks its original path by storingthe list identifier and the parent entry identifier of the listdescriptors within the memory of the controller. To avoid tracking thenavigation of the descriptors, techniques of the invention embedinformation regarding a parent list (also referred to herein as thefirst list) within the list descriptor as shown in FIGS. 5 through 7.This allows the controller to navigate the descriptors without storingthe identifiers of the list entry descriptor and parent entrydescriptors within the memory of controller 410.

FIG. 5 illustrates the parent descriptor information block 600 for achild list that may be placed in the child list descriptor's extendedinformation area. More particularly, the parent descriptor informationblock is placed at position 810 in list descriptor 800 as in FIG. 7 by aCREATE DESCRIPTOR command. Descriptor information block 600 alsoincludes list identifier 650 and object identifier 660 which are used bythe controller for accessing the parent entry. Fields such ascompound_length 610, info_block_type 620, primary_fields_length 630, anddescriptor_specifier_type 640 are general info block fields of theparent descriptor info block 600. The parent descriptor info block 600may be placed in the extended information field (i.e.extended_information field) 810 shown in FIG. 7.

FIG. 6 illustrates in one embodiment, a parent descriptor info block 700for a root list placed in the root list descriptor extended information.The parent descriptor info block is placed at 810 of list descriptor 800shown in FIG. 7. Fields such as compound_length 710, info_block_type720, and primary_fields_length 730, are general info block fields of theparent descriptor info block 700. One embodiment embeds informationabout the parent list within the list descriptor.

FIG. 7 illustrates the descriptor 800 with the extended informationfield. This descriptor structure applies to both root lists and childlists. When a controller moves backwards in a descriptor hierarchy, thecontroller can read information in the extended information field 810 todetermine the descriptor_specifier for opening its parent entry or SID.Therefore, controller 410, using the descriptor_specifier and the parentdescriptor 600, may navigate in a forward or a backward direction in thedescriptor hierarchy without storing information about the locations ofthe descriptors that the controller previously visited.

FIG. 8 is a flow diagram of one embodiment for using the new specifierfor accessing an entry descriptor. At block 300, a controller issues anOPEN DESCRIPTOR command with a descriptor_specifier specifying adescriptor by a list identifier (i.e. list_ID) and an object identifier(i.e. object_ID). At block 310, a target opens the descriptor. At block320, the descriptor is read by the controller using the samedescriptor₁₃ specifier.

FIG. 9 is a flow diagram of one embodiment for embedding informationabout the parent entry such as for a child list or SID such as for aroot list within the list descriptor for the purposes of navigatingdescriptors in a backwards direction. At block 910, a descriptorspecifier for the parent descriptor is placed at the end of the rootlist descriptor (e.g., extended_information field) or the child listdescriptor during a CREATE DESCRIPTOR command. The descriptor specifiermay specify an entry by a list identifier and an object identifier. Theroot list has a beginning (also referred to herein as a first position)and an end (also referred to herein as a second position). The newdescriptor specifier is placed in the second position for the root list.The child list also has a beginning position (referred to herein as athird position) and an end position (referred to herein as a fourthposition). The descriptor specifier is placed in the fourth position ofthe child list. At block 920, the parent descriptor, located in theextended information field of the child list descriptor, is used todetermine the descriptor specifier of its parent entry or the SID if thecontroller is currently reading a root list. At block 930, an OPENDESCRIPTOR command is issued with the descriptor_specifier for openingits parent entry (or SID) by a controller. Thus, the controllernavigates backward in the descriptor hierarchy.

FIGS. 10-16 illustrate methods for deleting a child list descriptor in adescriptor hierarchy BY USING THE NEW delete descriptor commandillustrated in FIG. 14. FIG. 10 illustrates one embodiment relating todeleting a child list by using the child list in thedescriptor_specifier. At block 1000, a child list descriptor is deleted.At block 1020, a child_ID is then deleted which is due to the child listdescriptor at block 1000 being deleted. At block 1030, has_child_IDattribute is updated to reflect that the child ID field has beendeleted. The has_child_ID attribute should be updated whenever thechild_ID is deleted because the has_child attribute, prior to deletion,is set to “1” which implies the child_ID field exists. When the child_IDfield does not exist, the has_child_ID attribute should be set to “0”.The value in the has_child_ID attribute indicates to another device suchas a controller whether a child list exists. At block 1040, anentry_descriptor_length is updated to indicate that theentry_descriptor_length is shorter after the child ID field has beendeleted. At block 1050, a list_descriptor_length is updated to alsoreflect that the list_descriptor₁₃ length has been shortened to indicatethat the child ID field has been deleted. It will be appreciated thatthe X represents a target descriptor in a descriptor_specifier.

FIG. 11 illustrates a child list being deleted by deleting the parententry descriptor. At block 1110, a child list descriptor is firstdeleted by using the new DELETE DESCRIPTOR COMMAND illustrated in FIG.14. At block 1120, the parent entry descriptor is deleted. At block1130, the no₁₃ of_entry_descriptors field is updated to reflect thatthere is one less entry descriptor in the list. At 1140, thelist_descriptor_length is updated to reflect that thelist_descriptor_length has been shortened.

FIG. 12 illustrates child lists being deleted by using the parent entrydescriptor's list in the descriptor_specifier. At block 1210, a childlist descriptor is deleted. At block 1220, a second child listdescriptor is deleted. At block 1230, a list descriptor, which is thetarget descriptor, is deleted.

It will be appreciated that an AV/C subunit may only delete leaf lists.Leaf lists are those lists that exist at the lowest level of thehierarchy such as child list descriptors (1210, 1220). This is due toleaf lists containing entry descriptors without child lists. If acontroller is to delete a particular list at a random location in thehierarchy, a subunit shell is required to search for all available liststo delete that which exists under that list. Thereafter, starting fromthe first leaf list, the subunit begins deleting. As the leaf lists aredeleted, their parent lists become leaf lists and are then capable ofbeing deleted.

It will be appreciated that when a root list is deleted, each individualdelete operation may involve one or more descriptors as illustrated atblocks 1210 and 1220 of FIG. 12.

In FIG. 13, at block 1310, a root list descriptor (which is also a leaf)is deleted by using the new DELETE DESCRIPTOR COMMAND illustrated inFIG. 14. At block 1320, the root_list_ID is deleted. At block 1330, thenumber_of_root_list_IDs field is updated to reflect the deletion of theroot list ID field. At block 1340, the SID_length is updated since theSID has shortened.

FIG. 14 illustrates the new DELETE DESCRIPTOR-control command that maybe used to delete various descriptors as described herein. Thedescriptor_specifier can specify a root list, child list, or an entry inwhich each of these may be deleted. When deleting entries, the DELETEDESCRIPTOR command should be issued on a descriptor opened by an AV/Ccontroller. The entry may then be deleted.

When deleting lists such as a root list or a child list, the DELETEDESCRIPTOR command should be issued on a closed descriptor to preventany access disruptions to other controllers. The result field describesthe result of the delete operation. The result field is set to 00₁₆ oninput to show that the delete operation has occurred successfully. Thisvalue of the result field can change in the response frame as shown inTable I. TABLE I Value of Result Field. Value of result meaning 00₁₆ Thetarget descriptor and all its child lists (if any) were deletedsuccessfully. 01₁₆ The target descriptor and some of its child listswere not deleted. Inspect the fields below in the command to determinewhich ones and the node IDs of the controllers that opened them. Allothers Reserved (i.e., values are not presently defined at this time,but these values may be defined in the future.)

The DELETE DESCRIPTOR command, when issued on a non-leaf descriptor,attempts a cascade delete process as described above. If any descriptorsare open for a read operation, then those descriptors should be forceclosed using a typical close command and thereafter deleted. If all thedescriptors in the hierarchy are deleted, then the target should returnan ACCEPTED response frame that should be the same as the command frame.If any descriptor cannot be deleted either directly or indirectlybecause its descriptor or related descriptors are open for a writeoperation, the command should return a REJECTED response. The DELETEDESCRIPTOR response frame is provided in FIG. 15. Thenumber_of_undeleted_descriptors fields are filled with the number ofundeleted list descriptors resulting from the DELETE DESCRIPTOR controlcommand. The number of undeleted_descriptors fields do not containinformation about entry descriptors.

The length of each descriptor_specifier is known by eachdescriptor_specifier type. If a descriptor has multiple open entries,then each of the descriptor specifiers and node_IDS should be returned.For descriptors that are not open and cannot be deleted because theirparent or children lists are open, a node_ID of 00 00₁₆ should bereturned to indicate that they are not open. The length of each openernode_ID should be two, since node_IDs are always two bytes in length.

FIG. 16 illustrates descriptor hierarchy being deleted when onedescriptor within a hierarchy is open for a write operation and onedescriptor is open for a read. If the AV/C controller is unable todelete the opened_for_write descriptors, the AV/C controller may issuean open descriptor NOTIFY command for each open descriptor to benotified when the descriptor is finally closed. The AV/C controller maythen reissue the same DELETE DESCRIPTOR command.

At block 1330, list 2 is open for a read operation. Consequently, list 2at 1330 is force closed. List descriptor 1340 is then deleted and theparent entry is updated. Descriptor 1350 is also deleted and the parententry updated. Leaf list descriptors 1370 and 1380 are not deletedbecause its parent entry inside list 1360 is access protected. However,root list descriptor 1330 is deleted and the parent entry updated toreflect the deletion of the root list. List descriptor 1360, which isopen for a write operation, is also access protected and therefore it isnot deleted. Additionally, root list descriptor 1320 keeps all theentries accept the entry with the deleted child list. Finally, SID 1310is not deleted. This provides a final result of descriptors that remainin the descriptor hierarchy as shown in FIG. 17. FIG. 17 illustratesthat lists 1330, 1340, and 1350 have been deleted from the descriptorhierarchy after the cascade delete process.

In the preceding detailed description, the invention is described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes may be made thereto withoutdeparting from the broader spirit and scope of the invention as setforth in the claims. The specification and drawings are, accordingly, tobe regarded in an illustrative rather than a restrictive sense.

1-44. (canceled)
 45. A method comprising: inserting parent informationinto a lower list descriptor in a hierarchy of descriptors representingaudio-video objects, the parent information identifying a higher entrydescriptor contained in a higher list description in the hierarchy, thehigher entry descriptor including child information that identifies thelower list descriptor.
 46. The method of claim 45, wherein the parentinformation comprises a description specifier that identifies the higherentry descriptor, the description specifier comprising a list identifiercorresponding to the higher list descriptor and an object identifiercorresponding to the object represented by the higher entry descriptor.47. The method of claim 46 further comprising: navigating up thehierarchy from the lower list descriptor to the higher entry descriptorusing the description specifier.
 48. The method of claim 46 furthercomprising: opening the higher entry descriptor using the descriptionspecifer.
 49. The method of claim 45 further comprising: creating thehierarchy of descriptors.
 50. A method comprising: receiving a deletedescriptor command comprising a descriptor specifier that identifies adescriptor in a hierarchy of descriptors representing audio-videoobjects, the descriptors comprising list descriptors containing entrydescriptors that reference list descriptors in a parent childrelationship, the descriptor specifier comprising a list identifier andan object identifier; and deleting one of a list descriptor and an entrydescriptor based on the descriptor specifier.
 51. The method of claim 50further comprising: updating a parent entry descriptor referencing achild list descriptor identified by the descriptor specifier; andupdating a list descriptor containing the parent entry descriptor. 52.The method of claim 50 further comprising: deleting a child listdescriptor referenced by a parent entry descriptor identified by thedescriptor specifier; and updating a list descriptor containing theparent entry descriptor.
 53. The method of claim 50 further comprising:deleting all child list descriptors referenced by parent entrydescriptors within a list descriptor identified by the descriptorspecifier.
 54. The method of claim 50 further comprising: propagatingdeletion of a descriptor down the hierarchy.
 55. The method of claim 54,wherein the deletion skips list descriptors that are open for writing.56. A machine readable medium having executable instructions to cause aprocessor to perform a method comprising: inserting parent informationinto a lower list descriptor in a hierarchy of descriptors representingaudio-video objects, the parent information identifying a higher entrydescriptor contained in a higher list description in the hierarchy, thehigher entry descriptor including child information that identifies thelower list descriptor.
 57. The machine readable medium of claim 56,wherein the parent information comprises a description specifier thatidentifies the higher entry descriptor, the description specifiercomprising a list identifier corresponding to the higher list descriptorand an object identifier corresponding to the object represented by thehigher entry descriptor.
 58. The machine readable medium of claim 57further comprising: navigating up the hierarchy from the lower listdescriptor to the higher entry descriptor using the descriptionspecifier.
 59. The machine readable medium of claim 57 furthercomprising: opening the higher entry descriptor using the descriptionspecifer.
 60. The machine readable medium of claim 56 furthercomprising: creating the hierarchy of descriptors.
 61. A machinereadable medium having executable instructions to cause a processor toperform a method comprising: receiving a delete descriptor commandcomprising a descriptor specifier that identifies a descriptor in ahierarchy of descriptors representing audio-video objects, thedescriptors comprising list descriptors containing entry descriptorsthat reference list descriptors in a parent child relationship, thedescriptor specifier comprising a list identifier and an objectidentifier; and deleting one of a list descriptor and an entrydescriptor based on the descriptor specifier.
 62. The machine readablemedium of claim 61 further comprising: updating a parent entrydescriptor referencing a child list descriptor identified by thedescriptor specifier; and updating a list descriptor containing theparent entry descriptor.
 63. The machine readable medium of claim 61further comprising: deleting a child list descriptor referenced by aparent entry descriptor identified by the descriptor specifier; andupdating a list descriptor containing the parent entry descriptor. 64.The machine readable medium of claim 61 further comprising: deleting allchild list descriptors referenced by parent entry descriptors within alist descriptor identified by the descriptor specifier.
 65. The machinereadable medium of claim 61 further comprising: propagating deletion ofa descriptor down the hierarchy.
 66. The machine readable medium ofclaim 65, wherein the deletion skips list descriptors that are open forwriting.
 67. An apparatus comprising: means for receiving parentinformation; and means for inserting the parent information into a lowerlist descriptor in a hierarchy of descriptors representing audio-videoobjects, the parent information identifying a higher entry descriptorcontained in a higher list description in the hierarchy, the higherentry descriptor including child information that identifies the lowerlist descriptor.
 68. The apparatus of claim 67, wherein the parentinformation comprises a description specifier that identifies the higherentry descriptor, the description specifier comprising a list identifiercorresponding to the higher list descriptor and an object identifiercorresponding to the object represented by the higher entry descriptor.69. The apparatus of claim 68 further comprising: means for navigatingup the hierarchy from the lower list descriptor to the higher entrydescriptor using the description specifier.
 70. The apparatus of claim68 further comprising: means for opening the higher entry descriptorusing the description specifer.
 71. The apparatus of claim 67 furthercomprising: means for creating the hierarchy of descriptors.
 72. Anapparatus comprising: means for receiving a delete descriptor commandcomprising a descriptor specifier that identifies a descriptor in ahierarchy of descriptors representing audio-video objects, thedescriptors comprising list descriptors containing entry descriptorsthat reference list descriptors in a parent child relationship, thedescriptor specifier comprising a list identifier and an objectidentifier; and means for deleting one of a list descriptor and an entrydescriptor based on the descriptor specifier.
 73. The apparatus of claim72 further comprising: means for updating a parent entry descriptorreferencing a child list descriptor identified by the descriptorspecifier; and means for updating a list descriptor containing theparent entry descriptor.
 74. The apparatus of claim 72 furthercomprising: means for deleting a child list descriptor referenced by aparent entry descriptor identified by the descriptor specifier; andmeans for updating a list descriptor containing the parent entrydescriptor.
 75. The apparatus of claim 72 further comprising: means fordeleting all child list descriptors referenced by parent entrydescriptors within a list descriptor identified by the descriptorspecifier.
 76. The apparatus of claim 72 further comprising: means forpropagating deletion of a descriptor down the hierarchy.
 77. Theapparatus of claim 76, wherein the means for deletion skips listdescriptors that are open for writing.
 78. A computer system comprising:a processor coupled to a memory through a bus; and a process executed bythe processor from the memory to cause the processor to insert parentinformation into a lower list descriptor in a hierarchy of descriptorsrepresenting audio-video objects, the parent information identifies ahigher entry descriptor contained in a higher list description in thehierarchy, the higher entry descriptor including child information thatidentifies the lower list descriptor.
 79. The computer system of claim78, wherein the parent information comprises a description specifierthat identifies the higher entry descriptor, the description specifiercomprising a list identifier corresponding to the higher list descriptorand an object identifier corresponding to the object represented by thehigher entry descriptor.
 80. The computer system of claim 79, whereinthe processor further causes the processor to navigate up the hierarchyfrom the lower list descriptor to the higher entry descriptor using thedescription specifier.
 81. The computer system of claim 79, wherein theprocessor further causes the processor to open the higher entrydescriptor using the description specifer.
 82. The computer system ofclaim 78, wherein the processor further causes the processor to createthe hierarchy of descriptors.
 83. A computer system comprising: aprocessor coupled to a memory through a bus; and a process executed bythe processor from the memory to cause the processor to receive a deletedescriptor command comprising a descriptor specifier that identifies adescriptor in a hierarchy of descriptors representing audio-videoobjects, the descriptors comprising list descriptors containing entrydescriptors that reference list descriptors in a parent childrelationship, and to delete one of a list descriptor and an entrydescriptor based on the descriptor specifier, wherein the descriptorspecifier comprises a list identifier and an object identifier.
 84. Thecomputer system of claim 83, wherein the processor further causes theprocessor to update a parent entry descriptor referencing a child listdescriptor identified by the descriptor specifier; and to update a listdescriptor containing the parent entry descriptor.
 85. The computersystem of claim 83, wherein the processor further causes the processorto delete a child list descriptor referenced by a parent entrydescriptor identified by the descriptor specifier; and to update a listdescriptor containing the parent entry descriptor.
 86. The computersystem of claim 83, wherein the processor further causes the processorto delete all child list descriptors referenced by parent entrydescriptors within a list descriptor identified by the descriptorspecifier.
 87. The computer system of claim 83, wherein the processorfurther causes the processor to propagate deletion of a descriptor downthe hierarchy.
 88. The computer system of claim 86, wherein the deletionskips list descriptors that are open for writing.